Automated facilities management system

ABSTRACT

An automated facilities management system has the ability to predict occupant behavior by identifying recurring patterns in the way that people use buildings and comparing them with environmental characteristics. This technology is not limited to human behavior patterns, but extends to any mechanical systems or data points that tend to vary in recurring patterns. The data processing is carried out by rules engines triggered by relational database modifications.

RELATED APPLICATIONS

This application claims the benefit of:

-   -   U.S. Provisional Application No. 61/379,714, entitled PATTERN        MATCHING FOR AUTOMATED ENERGY MANAGEMENT SYSTEM and filed on        Sep. 2, 2010;    -   U.S. Provisional Patent Application No. 61/379,715, entitled        RULES ENGINE FOR AUTOMATED ENERGY MANAGEMENT SYSTEM and filed on        Sep. 2, 2010; and    -   U.S. Provisional Patent Application No. 61/409,532, entitled        SYSTEM FOR MEASURING AND MANAGING GROUP COMFORT USING OCCUPANT        FEEDBACK and filed on Nov. 2, 2010.        The entire teachings of the above applications are incorporated        herein by reference.

BACKGROUND

Smart Building technologies are typically employed in an effort tomonitor and control elements of a building. In such systems, the variousbuilding subsystems are integrated into a network infrastructure with acommon user interface. The integrated subsystems typical includemechanical and electrical equipment such as Heating, Ventilation, andAir Conditioning (HVAC), lighting, power, fire, communications, andsecurity systems

While the Smart Building interface allows a user to manage HVAC andlighting, the functions are controlled by manually entering set points.While different zones can have differing set points and differing targettemperatures and lighting levels, the zones typically have a morning setpoint and an evening set point. After the morning set point, thethermostats and lighting controllers are set in anticipation of zoneoccupancy. Likewise, after the evening set point, the thermostats andlighting controller are set in anticipation of the zone beingunoccupied. The settings are usually dictated by building management toreflect standard work hours.

While weekdays, weekends, and holidays are recognized and programmeddifferently, workers who come in early or stay late may beuncomfortable. Likewise, zones that are vacant during a particularworkday will be treated and being occupied, wasting energy. Specialaction must be taken by building management to accommodate specialoccupancy requests, such as working on weekends or unusual hours. Toavoid this problem, set points are often left fully closed (occupiedsetting) around the clock, which is a substantial waste of energy.

SUMMARY

In the domain of Smart Buildings, the ability to predict future occupantneeds, and intelligently address those needs preemptively, is a verypowerful capability. For example, being able to predict accurately whena building or a section of a building will be occupied and preemptivelyadjust lighting and HVAC (Heating, Ventilation & Air Conditioning)optimizes occupant comfort. Conversely, being able to predict accuratelywhen buildings and sections of buildings will be unoccupied and settinglighting and HVAC for maximum energy savings during those periodsminimizes energy consumption. A particular automated facilitiesmanagement system also changes settings in anticipation of changes inoccupancy. For example, coasting is done well in advance of the timethat the space will be unoccupied. Doing all provides better comfort andenergy savings.

An automated facilities management system in accordance with particularembodiments of the invention has the ability to predict occupantbehavior by identifying recurring patterns in the way that people usebuildings and comparing them with environmental characteristics. Thistechnology is not limited to human behavior patterns, but extends to anymechanical systems or data points that tend to vary in recurringpatterns.

A particular embodiment of the invention includes a method forpredicting future behavior. That method includes:

-   -   collecting historical data related to a behavior;    -   processing the historical data into intervals related to the        behavior;    -   processing the intervals of historical data into a plurality of        patterns;    -   comparing current data related to the behavior with the patterns        to determine a best fit pattern that is most similar to the        current data; and    -   applying the data in the best fit pattern to predict future data        related to the behavior.

In more particular embodiments, the behavior can be a group behavior.Also processing the intervals of historical data can include performinga cluster analysis to identify the patterns. Additionally, comparing thecurrent data can include performing a cluster analysis to identify thebest fit pattern from the plurality of patterns. That cluster analysiscan weigh recent current data more than distant current data.

The intervals can be divided into an equal number of slices.Specifically, the slices can be consecutive time slices.

Furthermore, the method can include making adjustments in anticipationof the predicted data. In addition, the method can solicit feedback andmake adjustments in response to the feedback.

Another embodiment of the invention can include a system forautomatically managing a facility. The system can include:

-   -   a plurality of sensor devices providing sensed data;    -   a plurality of control devices for actuating facility devices;    -   a data store having a plurality of patterns related to the        sensor devices;    -   a processor coupled to the data store, the sensor devices, and        the control devices, the processor being responsive to the        sensed data over time from the sensor devices to:        -   store the sensed data over time in the data store;        -   calculate the best match pattern from sensed data over time            and the plurality of patterns;        -   predict future sensed data from the best match pattern; and        -   signal a control device based on the predicted future sensed            data.

Another particular embodiment of the invention can include an automatedcomputing system, including a database system and a rule.

The database system can store data in an organized structure and triggeran event upon modifications to the stored data. The database system caninclude an ACID-compliant relational database storing the data in tableswith data columns.

The rule can be responsive to the triggered event to process an actionbased on the stored data. The rule can include a rule definitionidentifying the data that triggers the rule. More particularly, the ruledefinition can include a list of data that triggers the rule. The rulecan also include an assigned priority.

As for the action, the action can succeed or fail and a failed actioncan be retained and can be restartable.

Another particular embodiment of the invention can include a moreparticular automated computing system, including a relational databasesystem and a plurality of rules.

The relational database system can store data in an organized structureof tables having columns of data. The relational database system canalso trigger an event upon modifications to the stored data. Inparticular, the relational database can be ACID compliant.

Each rule can include a list of table and column pairs in the relationaldatabase that trigger the rule and an action process responsive to aevent to the data stored in a table and column from the list, where theaction can process a subset of the stored data. The rule can furtherinclude an assigned priority.

In particular, the subset of stored data can include data not in thetable and column pairs. Also a plurality of instances of a same rule canexecute in parallel. Furthermore, instances of the same rule can betriggered by different table and column pairs. The triggering andexecution of the rules can be multi-threaded and/or asynchronous.

Furthermore, the action can succeed or fail and a failed action can beretained and can be restartable. More particularly, triggered rules canbe stored as entries in an execution queue. The rules entered in theexecution queue can be modified. Those modified rules can also beconsolidated.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescription of particular embodiments of the invention, as illustratedin the accompanying drawings in which like reference characters refer tothe same parts throughout the different views. The drawings are notnecessarily to scale, emphasis instead being placed upon illustratingthe principles of the invention.

FIG. 1 is a schematic block diagram of a particular automated facilitiesmanagement system.

FIG. 2 is a schema diagram for a simplified LEO database of FIG. 1.

FIG. 3 is a database schema diagram for a rules database used by therules engines of FIG. 1.

FIG. 4 is a pictorial diagram of an exemplary office having a simplifiedarray of sensors.

FIG. 5 is an exemplary normalized graph of all occupancy sensor readingsfor the office of FIG. 4 over a one-day time interval.

FIG. 6 is a graph showing the application of an exemplary occupancypattern of FIG. 5 to thermostat settings.

FIG. 7 is a graph showing a more detailed application of the exemplarypattern of FIG. 5 to thermostat settings.

FIG. 8 is a flowchart of the overall process for pattern detection,matching, and prediction.

FIG. 9 is a block diagram illustrating the process of calculating thesimilarity of sensor readings for two time intervals.

FIG. 10 is a flowchart for a particular precise method to identifyingclusters.

FIG. 11 is a flowchart for a particular heuristic method to identifyingpatterns.

FIG. 12 is a block flow diagram for a particular pattern matchingalgorithm on a LEO of FIG. 1.

FIG. 13 is a flowchart for the detailed process of determining thedefault pattern for a time interval in FIG. 8.

FIG. 14 is flowchart for the detailed process of dynamically updatingthe default pattern from FIG. 8.

FIG. 15 is a flowchart for the detailed process of retrieving apredicted value for a sensor from FIG. 8.

FIG. 16 is an exemplary graph illustrating the trade-offs in balancingenergy saving with occupant comfort.

FIG. 17 is a flow diagram illustrating the processing of feedback for acontrol zone within a subsystem.

FIG. 18 is an exemplary user interface for feedback devices.

FIG. 19 is a block diagram of a rule definition in accordance withparticular embodiments of the invention.

FIG. 20 is a flowchart of a particular rules engine in accordance withparticular embodiments of the invention.

FIG. 21 is a flowchart of rule triggering logic of FIG. 20.

FIG. 22 is a flowchart for translation of event queue entries into ruleexecution queue entries from FIG. 20.

FIG. 23 is a flowchart of rule execution logic of FIG. 20.

FIG. 24 is a flowchart of a process for translation of event queueentries into rule execution queue entries from FIG. 22 to include queueentry modification.

FIG. 25 is a block diagram of rule definition components of FIG. 19modified to support execution queue entry modification of FIG. 24.

DETAILED DESCRIPTION

An automated facilities management system in accordance with particularembodiments of the invention is useful in residential and commercialbuildings. In particular, the system can tailor a building's energyusage to known or derived occupancy patterns and the building's energyparameters. By doing so, energy can be more efficiently used when neededand conserved when not needed.

FIG. 1 is a schematic block diagram of a particular automated facilitiesmanagement system. The system includes a client-side infrastructure 2 ona Local Area Network (LAN) and a remote central hosting infrastructure8. The client-side infrastructure 2 communicates with the centralhosting infrastructure 8 via a Wide Area Network (WAN) 7, such as thepublic Internet.

The client-side infrastructure includes one or more Local EnergyOptimizers (LEO) 20-1, 20-2. Each LEO 20-1, 20-2 is responsible forexecuting a local energy conservation plan. A particular building mayrequire multiple LEOs, depending on various factors including networkinfrastructure. Indeed, each business operating within a building canhave one or more dedicated LEOs. The LEOs function autonomously, buteach will generally be embodied in a commercially-available desktop orlaptop computer having limited processing power and memory.

Each LEO 20-1, 20-2 is in communication with a plurality of facilitydevices 30 located throughout a monitored space. The facility devices 30include sensors 32 and controls (i.e. actuators) 37.

While the sensors 32 can directly communicate with the LEOs 20-1, 20-2,certain sensors 32 communicate via a separate sensor controller 34-2,such as a third-party Crestron controller. Example sensors include, butare not limited to:

-   -   occupancy sensors to detect the presence of a person, such as        Infrared motion sensors, Bluetooth, RFID, or other wireless RF        emitters, oxygen sensors, and manually activated switches (light        switches, computer keyboards, touch panels etc.);    -   temperature sensors to detect the temperature at the sensor;    -   gas detectors, such as carbon monoxide detectors;    -   humidity sensors; and    -   light sensors to detect the light level at the sensor.

Similarly, the LEOs 20-1, 20-2 forward commands to a plurality ofcontrols 37 to adjust the energy usage of the space. Examples of suchcontrols include, but are not limited to:

-   -   relays;    -   thermostats; and    -   light dimmers.

While the LEOs 20-1, 20-2 can directly communicate with the controls 37,such as in a residential environment, a particular embodiment of theinvention exploits third-party Building Management System (BMS)controllers 39-1, 39-2 to operate facility controls 37. Such BMScontrollers 39-1, 39-2, available from various sources, are typicallyinstalled in commercial buildings to control and monitor the building'smechanical and electrical equipment such as HVAC, lighting, powersystems, fire systems, and security systems.

In particular, commercial BMS controllers 39-1, 39-2 are programmed tooperate a network of control actuators 37 to obtain a desired result(e.g. temperature change). In other words, the building's BMScontrollers 39-1, 39-2 already know what systems need to be adjusted andhow each component in the system (dampers, mixing valves, etc.) needs tobe actuated to accomplish a result without compromising other parts ofthe system. What the BMS controllers lack is an understanding of when tomake macro adjustments such as zone temperature changes, instead relyingon human policy or configuration input. By integrating with the BMS, theLEOs automate the “when” part of the equation by predicting futureneeds. The actual protocols used to communicate with the BMS are productspecific.

More particularly, when to apply changes to HVAC settings inanticipation of a predicted change in occupancy is determined byestablishing the heating and cooling characteristics of the HVAC zonethrough regression analysis of the rate of change in temperature as afunction of HVAC heating or cooling demand, interior temperature,exterior temperature, and solar heating through windows. Thecoefficients derived from this analysis establish the characteristic ofthe zone. By applying these coefficients to actual conditions, the timeto heat or cool the space to the desired temperature can be determined.Once this time has been established, it can be applied to the predictedoccupancy and an optimal time to either actively heat or cool the space,or turn off active heating and cooling and let the temperature settle,can be determined. By continually performing this analysis, changes incoefficients will be indicators of changes in HVAC system performance orin building shell performance.

Data from the sensors 32 is stored in a local data store 29-1, 29-2 asrelational database tables 28-1, 28-2. Each LEO 20-1, 20-2 includes arespective rules engine 22-1, 22-2 for processing the stored sensor dataand signaling the controls 37 and BMS controllers 39-1, 39-2, ifnecessary. Each rules engine 22-1, 22-2 employs a respective rulesdatabase 24-1, 24-2 to manage data and processing. In a particularembodiment, the rules engines 22-1, 22-2 are implemented as WindowsServices under a Microsoft Windows operating system.

Also in communication with the WAN 7 and accessible by the LEOs 20-1,20-2 are logical sensors 74, which provide external data to the LEOs20-1, 20-2. Examples of logical sensors 74 include weather forecasts,such as provided by Google, Inc., climate models, electricity rates,time signals from time services, and other data feeds.

The LEOs 20-1, 20-2 communicate through the WAN 7 with a central server82 on the central hosting infrastructure 8. It should be understood thatthe database for an LEO can include data from sensors 32 that signalanother LEO, by receiving the sensor data over the LAN or via thecentral server 82. Specifically, the LEO will periodically send data tothe central server 80 for storage or transfer to another LEO. The LEOcan also send a request for data to the central server 80, where it willeither reply with data or timeout. Because the LEOs 20-1, 20-2 willtypically communicate through a firewall 40-1, 40-2, the communicationis initiated by the LEOs 20-1, 20-2 through an open firewall port (suchas a Hyper-Text Transport Protocol (HTTP) request through port 80).

The central server 80 is responsible for storing long-term data andoperating on the data, particularly pattern detection and analysis. Thecentral server 80 communicates with a data warehouse 89 storing arelational database 88. Human interaction with the system is through acomputer interface, such as a web client 27 (PC), 77 (smartphone), amobile client 76 or feedback devices 25 (smartphone), 26 (PC). Note thathuman interaction can also be initiated on the central hostinginfrastructure 8, depending on how implemented.

By disposing the central server 80 on the WAN 7, the data warehouse 89can be used to store historical data and patterns from numerous clientsources. That micro data can then be exploited to derive macro data foruse by energy utilities and energy brokers. To that end, a particularembodiment of the invention deploys the central hosting infrastructure 8on a commercial cloud computing system. Of course, the central server 80and data warehouse 89 can be disposed on the client LAN for clients,such as government entities, that desire or require secure control overits data and patterns.

The central data warehouse 89 stores historical data for each LEO 20-1,20-2 and each LEO 20-1, 20-2 locally stores current data at least untiltransferred to the central server 80, such as once per day (e.g.overnight transfer). Once the central data warehouse 89 stores asufficient amount of historical data, the historical data is processedby a server rules engine 82 on the central server 80 to detect patternsin the data. The rules engine 82 employs a server rules database 84 tomanage data and processing. Again, in a particular embodiment, the ruleengine 82 is implemented as Windows Services under a Microsoft Windowsoperating system.

One important measure of patterns is the occupancy rate of an office orhome as viewed over a period of time, such as daily. For example,instead of a building usage following a simple, weekday or weekendpattern there can be several usage patterns for both a weekday and aweekend. Knowing those patterns allows significant energy conservationby anticipating demand. In a particular embodiment, pattern detectionand recognition processing is performed at a convenient periodic time,such as on a weekly basis.

Once patterns are recognized, those patterns are useful for predictingfuture behavior, such as occupancy. Specifically, as long as occupancycan be correlated with a known pattern, it can be assumed that thepattern will continue at least for the near term. For that use, thevarious detected patterns are transferred to the LEO databases 28-1,28-2 for real-time matching.

FIG. 2 is a schema diagram for a simplified LEO database of FIG. 1. TheLEO database 28 is shown as a group of related data tables. The tablesinclude a clients table 280, a spaces table 281, a leos table 282, acontrollers table 283, a controllerattributes table 284, a devices table285, a deviceattributes table 286, a sensorsandcontrols table 287, asensororcontrollog table 288, and a timeslotlog table 289. It should beunderstood that the illustrated database is not a complete database, butinstead is meant to highlight some core aspects of the data.

The clients table 280 defines the installations of the management systemincluded in the database. The table columns include:

-   -   ClientID: Unique identifier for the installation    -   Name: A descriptive name for the installation

The spaces table 281 includes hierarchical definitions of the spaces(locations, buildings, floors, zones, rooms) of all installations. Thetable columns include”

-   -   ClientID: The installation that this space is within    -   NodeID: A unique identifier for this space within the        installation    -   Name: A descriptive name for this space

The leos table 282 includes entries for all LEOs within allinstallations. The table columns include:

-   -   ClientID: The installation that this LEO is installed at    -   LEOID: A unique identifier for this LEO within the installation    -   Name: A descriptive name for this LEO

The controllers table 283 includes entries for all interfaces tocontrollers, sensors or controls across all installations. The tablecolumns include:

-   -   ClientID: The installation that the interface is installed at    -   LEOID: The LEO that communicates with the interface    -   ControllerID: A unique ID for this interface on this LEO

A controller represents an interface to a third-party controller or anetwork interface and protocol to a bank of directly controlled sensorsand controls. The controllerattributes table 284 controls meta datadescribing the controller. Controllers are associated with LEOs. Theseare physical associations.

The controllerattributes table 284 thus includes entries that define theattributes for each controller, such as the type of interface (BMS,Bluetooth, ZigBee), the address of the interface, and any otherinterface-specific meta data. The table columns include:

-   -   ClientID: The installation that the interface is installed at    -   LEOID: The LEO that communicates with the interface    -   ControllerID: A unique ID for this interface on this LEO    -   Attribute: A controller-unique name for the attribute    -   Value: The value of the attribute

The devices table 285 includes an entry for each device (sensor orcontrol). The table columns include:

-   -   ClientID: The installation that the device is installed at    -   LEOID: The LEO that communicates with the interface    -   ControllerID: The controller that this device is interfaced        through    -   DeviceID: A controller-unique ID for this device    -   SensorOrControlID: If not null, the sensor or control that        should receive send data to or from this device    -   Name: A descriptive name for this device

Notice that sensors and controllers are directly tied to spaces. Theseconnections may be physical or logical. The connection between sensorsand controls to LEOs is through devices and controllers.

The deviceattributes table 286 includes entries that define attributesfor each device, such as the network address. The table columns include:

-   -   ClientID: The installation that the device is installed at    -   LEOID: The LEO that communicates with the interface    -   ControllerID: The controller that this device is interfaced        through    -   DeviceID: The ID for this device    -   Attribute: A device-unique name for the attribute    -   Value: The value of the attribute

The sensorsandcontrols table 287 includes entries for all sensor values,control settings and intermediate values used by rules. The tablecolumns include:

-   -   ClientID: The installation that this value is used by    -   SensorOrControlID: A client-unique ID for the value    -   Name: A descriptive name for this value    -   NodeID: If not null, the ID of the space (zone, room, . . . )        that the sensor or control is associated with    -   Type: “Binary”, “Range”, “String”, or “Timer”. The type of        value.    -   Read: If 1, indicates that the value is read from a sensor    -   Write: If 1, indicates that changes in the value need to be        written to a control    -   Log: If 1, indicates that any changes in the value must be        transmitted to the central server    -   Visible: If 1, indicates that the value should be visible        through the reporting interfaces    -   Scale: Constant used for normalization    -   Class: The class of value, like temperature, motion, light, . .        .    -   BinaryValue: Contains the value if Type=“Binary” and the alarm        status is Type=“Timer”    -   RangeValue: Contains the value if Type=“Range” and the countdown        timer if Type=“Timer”    -   StringValue: Contains the value if Type=“String”

The sensororcontrollog table 288 includes the new value and time oftransitions for sensors and controls. The table columns include:

-   -   ClientID: The installation that the sensor or control is        installed at    -   LogID: Unique identifier for this entry in the table    -   SensorOrControlID: The ID of the sensor or control    -   Value: A string representing the new value of the sensor or        control    -   TimeStamp: The date and time of the transition

The timeslotlog table 289 includes average values for a sensor orcontrol across a time slot. The table columns include:

-   -   ClientID: The installation that the sensor or control is        installed at    -   SensorOrControlID: The ID of the sensor or control    -   StartTime: The date and time of the start of the time slot    -   Average: The average value of the sensor or control during the        time interval

FIG. 3 is a database schema diagram for a rules database used by therules engines of FIG. 1. The rules database 24 is shown as a group ofrelated data tables. The tables include a classes table 241, a rulestable 242, a rule_parameters table 243, an event_queue table 244, and arule_queue table 245. Here again, it should be understood that theillustrated database is not a complete database, but instead is meant tohighlight some core aspects of the data.

The classes table 241 defines the base classes for rules and includescolumns with meta data for loading the code implementing the classes.The table columns include:

-   -   ClassName: Unique name for the class    -   AssemblyPath: Contains the storage path to the folder containing        the assembly containing the class assembly file.    -   AssemblyFile: Contains the file name of the assembly class file.    -   AssemblyClass: The name that the class is registered as in the        assembly class file

The rules table 242 defines all rules. It includes an entry for allrules being used by the application running on the rules engine. Thetable columns include:

-   -   RuleName: Unique name for the rule.    -   Description: A short description of the rule.    -   ClassName: The name of the class from which the rule is derived.    -   Priority: The priority that the rule will run at (1 and up).        Smaller values are higher priorities.

The rule_parameters table 243 is used when deriving multiple rules froma single class. It may, for example, define the table(s) and column(s)that the rule will be triggered by and perform actions on. The tablecolumns include:

-   -   RuleName: Name of the rule the parameter customizes.    -   ParameterName: Rule-unique name of the parameter.    -   ParameterValue: Value of the parameter.

The event_queue table 244 includes a FIFO (First In, First Out) queue ofevents. The table columns include:

-   -   EventID: Unique ID for the event    -   TableName: Name of the table that triggered the event    -   ColumnName: Name of the column that triggered the event    -   Action: “Insert”, “Update” or “Delete”. Contains the verb of the        SQL statement that triggered the event.    -   PrimaryKeys: Encoded string containing the values of the primary        key fields of the row that triggered the event

The rule_queue table 245 includes an entry for each rule that is queuedfor execution, running, or has failed. The table columns include:

-   -   RuleID: A unique ID for the rule instance (multiple instances of        the same rule, triggered by different events, may exist in the        queue)    -   RuleName: The name of the rule    -   TableName: The name of the table that triggered the rule    -   ColumnName: Name of the column that triggered the rule    -   PrimaryKeys: Encoded string containing the values of the primary        key fields of the row that triggered the rule    -   InstanceParameters: String that further defines the data the        rule should act on. May be set when a rule is scheduled by        another rule or by external code    -   Action: “Insert”, “Update” or “Delete”. Contains the verb of the        SQL statement that triggered the rule    -   State: “N” (waiting to run), “W” (running), “R” (running to be        rescheduled after completion), or “F” (failed)    -   Priority: Priority of the rule    -   Scheduled: The date and time the rule was scheduled or        rescheduled    -   Exception: Information about the nature of the failure when        State=“F”

With the basic structure of the system and its databases, the detailedprocessing will now be described.

FIG. 4 is a pictorial diagram of an exemplary office having a simplifiedarray of sensors. The office includes a number of office spaces, cubiclespaces, and meeting spaces. As shown, infrared motion sensors IR-1 . . .IR-10 are dispersed throughout the office. In addition, a Bluetoothreceiver BT is centrally located and paired with employee Bluetoothdevices (mobile phones, etc.). It should be understood that many moresensors can be deployed and interfaced with an LEO to detect and measureoccupancy.

The communication between the IR sensors and the LEO (not shown) isdetermined by the sensor manufacturer. Some manufacturer will signalwhenever a change is detected, and some will periodically signal. Forthis example, it is assumed that the IR sensors signal changes. Also,the Bluetooth emitters are periodically polled on a rolling basis,generally cycling every few seconds depending on the number of emittersand system load.

In the early morning, the office would typically be unoccupied so allthe sensors are inactive. From the database, we can determine whenemployees left the office by looking at data stored for their respectiveBluetooth (cell phone) emitters.

As the workday begins, Bluetooth emitters from cell phones and signalsfrom the IR detectors will begin to be reported as active. Throughoutthe day motion continues to be detected throughout the office. Somepeople may come and go, and others will move around to continuallypopulate the database.

As the workday comes to an end, people will begin leaving the office sosensor activity will decrease. Some people may stay later than othersbut typically, everyone will leave for the night. Sporadic activity maybe detected from cleaning crews, security patrols, and employeesreturning to the office to work or to retrieve forgotten items. Peoplefitting those demographics usually do not require a change in theenvironmental settings.

As can be appreciated, occupancy and usage patterns of a space can betracked and plotted. To that end, the data changes are logged forforwarding to the central server 80. The central server 80 analyzes thehistorical data. In particular, the central server 80 performsstatistical analysis to recognize patterns in the data, such asoccupancy patterns. Further analysis can provide more individualizedinformation, such as individual space usage patterns.

FIG. 5 is an exemplary normalized graph of all occupancy sensor readingsfor the office of FIG. 4 over a one-day time interval. To create thegraph 100, all occupancy-related sensor readings are transformed intoaveraged readings over fixed time slices 102 along the horizontal axis.The data is then normalized between values of 0-1, as shown by thevertical axis. The resulting pattern 105 represents the occupancy levelsof the space throughout the day.

The length of the time slices is chosen to match the application of thepattern, which in an HVAC application is a function of balancing dataoperations performance against providing balanced energy efficiency. Forexample, when controlling heating and cooling, a 15-minute time slice isa typical choice that strikes a balance between the amounts of datagenerated and the granularity required for optimum comfort. The timeslice can be variable over time, based on circumstances. So if dataquantities were moderate, and comfort could be enhanced by shorter timeslices, the time slices for a space could be shortened.

By averaging sensor values, the system determines the probability ofcertain behaviors for various time intervals with similarcharacteristics (such as day of week). The patterns act as a predictorof sensor values for a given time slices in the future, especially thenext time slice. To that end, the system gathers sensor data over time,groups the data by time intervals with similar characteristics, thencompares new time intervals with similar characteristics to findmatches. If a match is found, the system predicts sensor values in thenew time interval by recalling the values found in the past timeintervals with similar characteristics. Because sensor values areindicative of specific human behaviors, such as occupancy, the systembecomes reliable in the prediction of such human behavior.

Once the human behavior is patterned, the results can be used infacilities management. Specifically, predictions based on the patternsare used to tailor temperature and lighting levels to the environment.The patterns can also be used to examine other facility metrics, such asspace usage and planning. For example, individual schedules can bemonitored to see if people really use scheduled rooms. Rooms can also beconsolidated into common zones. Another example application ofscheduling involves factory scheduling and school schedule.

In addition to human behavior, the system is sensitive to changes in theelectrical and mechanical performance of the building. If the facilitiesequipment and physical building do not behave or respond as expected,those deviations can be logged. As such, the facilities managementsystem can perform monitoring-based commissioning of the facility.

FIG. 6 is a graph showing the application of an exemplary occupancypattern of FIG. 5 to thermostat settings. The graph 110 shows theexemplary occupancy pattern 105 for the office environment. As shown,the pattern 105 is a series of averaged sensor readings over a pluralityof consecutive time slices 102.

Viewing the data, the pattern 105 can be divided into multipleoperational segments. The office is occupied from the morning until theevening, with some people coming in earlier than others and some peopleleaving later than others. There is no overnight occupancy. During theoccupied working hours segment 115, the HVAC plan can focus onoptimizing employee comfort. During the overnight segments 117 a, 117 b,the office is generally unoccupied and the HVAC system can focus onmaximizing savings. During morning and evening standby segments 119 a,119 b, people are entering or leaving for the day and the HVAC plan canmaintain an intermediate setting by either ramping up the HVAC systemduring the morning segment 119 a, or allowing the HVAC system to coastto the overnight setting during the evening segment 119 b.

When exactly the HVAC system is initially ramped up or begins coastingwill depend on the thermal characteristic of the building. It isunderstood that the thermal characteristics of the building are notstatic or predefined. Instead, the system determines the rate at whichspace gains or dissipates heat as part of its normal operation, therebyself-learning the thermal characteristics that contribute to the “when”the ramping up or coasting begins.

FIG. 7 is a graph showing a more detailed application of the exemplarypattern of FIG. 5 to thermostat settings. Again, the graph 120 shows theexemplary occupancy pattern 105 at 15-minute time slices 102. Alsoshown, the pattern 105 is used to determine a target indoor temperature127. Also shown are plots of the outside air temperature 129, theheating thermostat set point 122, and the cooling thermostat set point128. In a commercial embodiment utilizing a BMS, the set points arecomputed by the BMS controller 39-1, 39-2 (FIG. 1). The temperature andoccupancy values are also normalized to a 0-100 range based on the rangeof sensor values in the raw historical data.

It should be understood that the predicted pattern depends on the timeinterval characteristics. Characteristics are data that describe objectsand time interval characteristics are data that describe time intervals.For example, in an office environment, occupancy is typically differenton weekdays as opposed to weekends. Thus, the day of the week (e.g.,Wednesday) is a characteristic of a “24-hour period starting and endingat midnight”, and one that has an obvious relevance to the occupants ofa space. Depending on the situation, a large number of othercharacteristics can be relevant. Examples include, but are not limitedto:

-   -   Season    -   Current weather        -   Temperature        -   Amount of sunlight        -   Wind    -   Weather forecast    -   Holidays        -   The particular holiday itself        -   The nature or category of holiday        -   The week containing the holiday    -   Fiscal year status    -   Major projects    -   Epidemics    -   Academic calendar

The system initially performs general pattern detection across all timeintervals, disregarding characteristics such as the day of the week. Theresult is a number of patterns, each of which is characterized byaverage sensor values for each time slice, the number of time intervalsthat were used in generating the pattern, and the “density” of thepattern. Density is a measure of how similar the sensor data is acrossall the time intervals used to generate it. Patterns that are generatedfrom many time intervals and are “dense” are strong indicators ofrecurring sensor data, and therefore strong predictors of future sensorvalues.

After the patterns have been ascertained, they are matched against timeinterval characteristics. For all time intervals that match a givencharacteristic, the system determines which pattern is the best fit. Theresult is a count for each pattern of the number of time intervals forwhich it was the best fit. The pattern that has the highest count ofbeing the best fit is considered the best match for the selectedcharacteristic. That best fit match is then used as a basis forpredicting future behavior for facilities management.

FIG. 8 is a flowchart of the overall process for pattern detection,matching, and prediction. The process begins at the server withretrieving sensor data from stored historical time intervals 1005, fromwhich recurring patterns are detected at step 1010. The recurringpatterns are then saved to storage 1015 for sharing with the clientLEOs.

On the client-side, the stored recurring patterns 1015 are combined atstep 2030 with the previously stored characteristics of the timeinterval 2025 to find a default pattern from time intervals with similarcharacteristics. That default pattern is then used as the initialcurrent pattern 2050 at step 2030.

Pattern matching is now done against current time interval 2060, whichhas a starting time slice 2060 ₁, a current time slice 2060 _(K), and anending time slice 2060 _(N) For the elapsed time period 2070 from thestarting time slice 2060 ₁ to the last completed time slice 2060 _(K-1),current data for each time slice 2060 ₁, . . . , 2060 _(K-1) is comparedagainst data in a respective time slice 2050 ₁, . . . , 2050 _(K-1) inthe current pattern 2050. The recurring patterns 1015 are also combinedat step 2040 with sensor data from elapsed time slices 2015 to find thebest match and use as the current pattern if a better fit is found thanthe previously selected current pattern.

Based on the sensor data in the current pattern, the process predictsfuture sensor data at step 2080. It should be understood that theprediction is most accurate for the current time slice and the next timeslice in the future, while the prediction becomes less reliable as theymore farther in the future. Once data collection for the current timeslice completes, the matching algorithm at step 2040 and predictionalgorithm at step 2080 are processed again, and iterative continuesafter each new time slice.

The algorithms used for pattern detection and matching are driven by atradeoff between accuracy and performance. That compromise aims toachieve an optimum balance between accuracy, responsiveness, andcomputing resource consumption. The algorithms for measuring similarityof sensor readings between two time intervals and the heuristicalgorithm for detecting recurring patterns in a large number of timeintervals were developed with this balance in mind.

As an overview, every time a selected sensor value differs from theprevious reading of the sensor, the date and time of the transition andthe new sensor value is stored in a log file. At the end of each timeslice, the average values for the selected sensors are calculated andstored with the date and time of the time slice in an averaged sensorvalue log file. The average values for all the selected sensors arenormalized for equal weighting to ensure that all sensors have the sameeffect on the similarity calculations. A typical normalization formulaadds a base value and multiplies the result with a factor to yield thesame range of values for all the sensors. A typical normalization willmap all sensor values into a numerical range from 1 to 100.

The general normalization equation is:

R _(n) =N _(min)+(R _(a) −R _(min))*(N _(max) −N _(min))/(R _(max) −R_(min))

where R_(n) is the normalized value, R_(a) is the average sensor value,R_(min) is the smallest value the sensor can return, R_(max) is themaximum value the sensor can return, N_(min) is the smallest possiblenormalized value, and N_(max) is the largest possible normalized value.In some cases it may be desirable to select R_(min) and R_(max) as thesmallest and largest typical sensor values as opposed to the smallestand largest possible sensor values.

The normalized average sensor value is stored in a log file with thetime slice for which it was calculated.

FIG. 9 is a block diagram illustrating the process of calculating thesimilarity of sensor readings for two time intervals. As shown, theprocess 1110 divides time intervals into N equal-sized time slices 1112₁, . . . , 1112 _(N) and 1122 ₁, . . . , 1122 _(N). For each time slice,a data value 1114 ₁, . . . , 1114 _(N), 1116 ₁, . . . , 1116 _(N) and1124 ₁, . . . , 1124 _(N), 1126 ₁, . . . , 1126 _(N) is stored for eachsensor.

The first step 1130 is to calculate the similarity of sensor values foreach corresponding time slice in the two time intervals. The time slicesimilarity function is:

$S_{T} = \sqrt{\frac{\sum\limits_{I = 1}^{M}\left( {R_{I\; T\; 1} - R_{I\; T\; 2}} \right)^{2}}{M}}$

where S_(T) is the calculated similarity for time slice T, R_(IT1) isthe normalized average sensor value for sensor I in time slice T fortime interval 1, R_(IT2) is the normalized average sensor value forsensor I in time slice T for time interval 2, and M is the number ofsensors chosen for the calculation.

Once the similarity of individual time slices within a time interval arecalculated, the overall similarity of the two time intervals iscalculated at step 1140 as:

$S_{O} = \sqrt{\frac{\sum\limits_{T = 1}^{N}S_{T}^{2}}{N}}$

where S_(T) is the similarity of sensor readings for time slice T, and Nis the total number of time slices in a time interval.

The calculated value of similarity becomes zero when the sensor readingsare identical across all time slices. Thus small values indicate a highdegree of similarity and large values indicate significant differencesin sensor readings. In accordance with a particular embodiment of theinvention, the time slices are considered to be suitably similar ifS_(o)≦100.

While a distance of 100 or less implies similarity in accordance with aparticular embodiment. This value can be modified over time bydetermining what values deliver the best patterns. “Best” meansdelivering the largest number of patterns. High values deliver few,large patterns. Too small values will not deliver any patterns. It isanticipated that a few times a year, all historical data is analyzed todetermine an optimal value. It should be appreciated that the optimalvalue is dependent on the characteristics of the space. For example, aresidence will have a different optimal value than a commercial officespace.

To detect recurring patterns of sensor readings, clusters of similartime intervals must be identified. Two approaches will now be described.The first approach is a precise approach that is guaranteed to identifyall clusters, but scales poorly. The second approach is a heuristicapproach that has been shown to find almost all possible clusters, butwhich does scale well.

The precise method was used during the development of the heuristicmethod to validate that they generated the same or very similarpatterns. As increasing amounts of data is collected, or questions areraised about the accuracy of the heuristic algorithm, the precisealgorithm can be used as a baseline for validation or improvements ofthe heuristic approach.

FIG. 10 is a flowchart for a particular precise method to identifyingclusters. The first step 1210 in the method 1200 is to create an initialset of two-member clusters that includes all possible pairs of timeintervals with similarities no greater than an absolute maximum clustersize; a value chosen to ensure that clusters really represent similarpatterns. The value is chosen by analyzing a representative data setwith different settings. The setting that yields the bestpatterns/clusters becomes the chosen setting. “Best” will depend on theapplication. For this embodiment, “best” was defined as yielding thelargest number of patterns.

Furthermore, a cluster also must have a minimum number of members. Forthis embodiment, three was chosen. The choice is application dependentand driven by whether there is a need or desire to yield patterns withsmall data sets, and the existence of a need for large numbers ofpatterns with large data sets.

The method then enters an iterative loop at step 1220 where all timeintervals are tested against all clusters in which they are not alreadya member. At step 1220, for each cluster, all possible clusters arecreated with one additional member, but not exceeding the absolutemaximum cluster size. If the addition of the time interval to thecluster does not cause the cluster to exceed the maximum cluster size,the time interval is added to the cluster. The iterative loop continuesthrough step 1230 until a pass does not add any time intervals to anyclusters. All possible clusters no larger than the absolute maximumcluster size are thus identified.

Two additional steps are performed. First, at step 1240, all clustersless than a certain size are eliminated. An optimal cutoff size dependson the data, but typically one to two orders of magnitude smaller thanthe total number of time intervals contributing to the process. Next, atstep 1250, the process eliminates overlapping clusters, i.e. clustersthat share members. The approach is to eliminate all but the clusterwith the largest number of members from the overlapping set. If multipleclusters are of the same size, the one with the highest density isretained.

FIG. 11 is a flowchart for a particular heuristic method to identifyingpatterns. The heuristic method 1300 for pattern detection starts at 1310by creating a list of all possible pairings of time intervals sorted bysimilarity, smallest first.

The rest of the algorithm runs in a loop that starts at step 1320 withpicking the similarity of the first pair in the list as a currentmaximum cluster size for this iteration. Viewed graphically, the newmaximum cluster size is a diameter equal to the distance between thefirst pair in the list. At step 1330, the method then determines if anyexisting clusters can be combined into a single cluster withoutexceeding the current maximum cluster size. Those that can are merged.At step 1340, the method then determines if any of the time intervals(e.g. days) that are not already in a cluster can be added to any of theexisting clusters without exceeding the current maximum cluster size.Then at step 1350, all pairs from the list that have similarities notgreater than the current maximum cluster size, and where none of the twoare members of a cluster, are added to the clusters. The final step 1360of the iterative loop is to remove all pairs where at least one memberof the pair has been assigned to clusters. The iteration stops when thesimilarity of the smallest pair in the list exceeds the maximum clustersize, or there are no more unassigned time intervals.

Regardless of which method is employed, every detected cluster is thesource for a pattern. In particular, each pattern is the sensor valueaverages from all members of the cluster across each time slice in thetime interval. The collections of patterns are stored by the server andtransferred to the LEOs at an appropriate time, such as over a weekend.Each LEO then begins using the patterns in its matching algorithms.

FIG. 12 is a block flow diagram for a particular pattern matchingalgorithm on a LEO of FIG. 1. As shown, the matching process 1400compares a pattern 1410 to a current time interval 1420 with analgorithm similar to the one used to compare time intervals with eachother for pattern recognition in FIG. 9. Instead of comparing historicaldata, pattern matching compares the current stream of sensor data valuesto the recognized patterns.

For pattern matching, the general time slice similarity function is:

$S_{T} = \sqrt{\frac{\sum\limits_{I = 1}^{M}\left( {\left( {R_{IP} - R_{IT}} \right)*\left( {1 - \left( \left( \frac{\left( {T_{N} - T_{T}} \right)}{T_{S}} \right) \right)} \right)^{2}} \right.}{M}}$

where S_(T) is the calculated similarity for time slice T, R_(IP) is thenormalized average sensor value for sensor I in time slice T for thepattern, R_(IT) is the normalized average sensor value for sensor I intime slice T for the time interval, M is the number of sensors chosenfor the calculation, T_(N) is the time of the current time slicerelative to the start of the time interval, T_(T) is the time of thetime slice being measured relative to the start of the time slice andT_(S) is the length of a time slice.

One difference between this formula and the one used for patterndetection is that differences are weighted by the time differencebetween the start of the current time slice and the start of the timeslice being measured. The current time slice difference is given aweight of one, and a time difference of a full time slice away is givena weight of zero.

The weighting can be made non-linear by applying an exponent to theweighting factor as below.

$S_{T} = \sqrt{\frac{\sum\limits_{I = 1}^{M}\left( {\left( {R_{IP} - R_{IT}} \right)*\left( {1 - \left( \left( \frac{\left( {T_{N} - T_{T}} \right)}{T_{S}} \right) \right)^{P}} \right)^{2}} \right.}{M}}$

where P is the exponent applied. The weighting makes differences thatare recent in time carry more weight than differences that are moredistant in time.

The overall similarity of the pattern to the time interval is

$S_{O} = \sqrt{\frac{\sum\limits_{T = 1}^{N}S_{T}^{2}}{N}}$

where S_(T) is the similarity of sensor readings for time slice T, and Nis the total number of time slices in a time interval.

FIG. 13 is a flowchart for the detailed process of determining thedefault pattern for a time interval in FIG. 8. Typically, time intervalswill have characteristics 2025 that are relevant to energy management asoutlined above. First, the sensor data from all historical timeintervals 1005 and the characteristics of the time intervals 2025processed at step 2032 to select historical time intervals with similarcharacteristics 2033. For characteristic values (e.g., the day of theweek), patterns are ranked at step 2034 by comparing each pattern 1015with sensor data for each historical time interval having similarcharacteristics 2033.

At step 2036, the process counts the number of times a particularpattern is the best match for a time interval. Then, at step 2038, thepattern that has the highest count of being the best match becomes thedefault pattern for the given time interval 2050.

For each time interval characteristic, the pattern with the highest rankbecomes the default pattern for that characteristic. The defaultpatterns, the characteristics, and the number of times the patterns isthe best match for the characteristic are stored for prediction ofsensor values. It should be appreciated that the choice of the defaultpattern is dynamic and can thus change as frequently as every timeslice.

FIG. 14 is flowchart for the detailed process of dynamically updatingthe default pattern from FIG. 8. The process 2040 begins at step 2042,where at the start of each time slice, the average sensor values for thecurrent time interval 2015 are matched against all patterns 1015 and thepattern with the best match is stored 2055. At step 2044, the storedbest match 2055 is compared to the stored current pattern 2050. At step2045, if another pattern is a better match than the currently selectedcurrent pattern 2050, the pattern with the best match 2055 becomes thenew current (i.e. default) pattern at step 2048; otherwise the currentpattern 2050 is continued as the default pattern at step 2046. Thisapproach ensures that the current pattern reflects actual sensor dataand is adaptive to changes in behavior and usage. In particular, thesystem has the ability to recognize when an exception has occurred andto change the current pattern to a more appropriate one

FIG. 15 is a flowchart for the detailed process of retrieving apredicted value for a sensor from FIG. 8. To predict a future sensorvalue at step 2084, the average sensor value stored for the currentpattern's time slice 2081 is used at step 2082, where the predicted timeslice 2050 _(X) is that time slice in the current time interval to bepredicted. Note that this is an average, and depending on the sensor,interpretation of the average sensor value meaning can vary. Forexample, for an occupancy sensor, a value of 0.5 may indicate thatoccupancy is likely to start or end half-way through the time slice.

How far out in the future to retrieve a predicted sensor value isdependent on the actual application. For HVAC, the time needed to bringthe building to the desired temperature is the major factor. This timewill vary with the thermal properties of the building and with the rangethat the temperature needs to change by, which, in turn may vary by theoutside temperature. The times can also be different for heating andcooling.

While the above pattern detection and matching processes have beendescribed with reference to time slices, the horizontal dimension can beother metrics other than time. An example of non-time based patterns ismonitoring how a failure of vehicle parts relate to the mileage of thevehicle. That is, if the failure of various parts are mapped into themileage across a large population of vehicles, patterns will emerge. Theemergence of new patterns, occurring at lower mileages, may indicatedeteriorating quality of a part.

To accomplish balanced energy efficiency, a particular embodiment of thesystem includes logic to understand how comfortable the occupants of abuilding are, and how comfortable they should be. The determination ofhow comfortable occupants “should be” includes an element of corporateor institutional policy that must be considered, and is accounted for inthe system algorithms as well. In particular, the system uses occupantfeedback to determine the comfort status of groups of occupants, anduses that as a factor in governing the settings of building subsystemsto optimize group comfort, while balancing against policy driven energysavings requirements.

By employing feedback, people are treated as fuzzy sensors (e.g. “toohot”, “too cold”, “just right”). Feedback then is thus data, from whichthe system can extract information, and treated as complaints. Thusfeedback is actively solicited, unlike complaints, because more data isbetter.

FIG. 16 is an exemplary graph illustrating the trade-offs in balancingenergy saving with occupant comfort. As shown, increasing comfort maydecreases energy efficiency. A goal of the system is to attempt tomaximize productivity by balancing comfort with efficiency, whilerecognizing that some increased energy costs may be overcome byincreased productivity.

In most buildings, efficient facilities management requires striking abalance between reducing energy consumption and optimizing occupantcomfort. In environments such as businesses, institutions and agencies,the comfort of an employee is an important factor in their overall jobsatisfaction and has a direct impact on their morale, productivity andemployee retention. Whereas reducing energy consumption means savingmoney, one cannot lose sight of the costs associated with unhappyemployees. The costs associated with reduced productivity or low ratesof retention can be substantial, and have the potential to outweighenergy savings gained at the expense of comfort. Therefore, finding theperfect balance between reducing energy consumption and keeping peoplecomfortable is an important strategic goal of most commercial entities.

A particular facilities management system includes the ability tomeasure occupant comfort and apply the results to facilities management.The system facilitates and encourages occupant feedback by providingeasy and entertaining feedback interfaces on familiar devices such assmart phones and personal commuters, and by responding to the occupant'sfeedback in a way that makes the occupant understand the functioning ofthe system and remain eager to participate. Encouraging full and activeoccupant feedback participation allows for accurate statistical analysisand reliable determination of group comfort.

Subsystems will have overlapping, but often different control zones. Forexample, a room may be the entire control zone for lighting control, butone of several rooms that are a single HVAC control zone. When feedbackis received, the location of the feedback is mapped into all of thecontrol zones that the location is part of. Typically, but notnecessarily, feedback for a given subsystem is handled independently offeedback from other subsystems. Feedback that an occupant finds that aspace is too brightly lit may affect the lighting or window shadesettings, but will not affect temperature handling.

Occupant feedback is implemented through a cycle of collecting feedbackfor a given period of time, the measurement period, then analyzing thefeedback to identify differences between group comfort and currentsubsystem settings adjustments, and finally making adjustments tosubsystem settings as appropriate. The cycle repeats continuously asfeedback is received.

FIG. 17 is a flow diagram illustrating the processing of feedback for acontrol zone within a subsystem. The process 3100 can be viewed as aCollection-Analysis-Adjustment cycle.

The collection phase addresses collecting feedback received fromfeedback devices at step 3110 for a fixed time period. The measurementperiod length for each collection phase is determined on acustomer-by-customer basis to account for:

-   -   the cycles of space occupancy and use;    -   the desired frequency of feedback-based adjustments; and    -   the quantity of feedback collected during each collection phase.

It should be noted that too short of a measurement period may result inundesirable fluctuations in settings based on too few instances offeedback. However, too long of a measurement period may result inundesirable delays between feedback and noticeable changes in subsystemsettings or feedback response. System reports can assist the customer inselecting the most appropriate measurement period. The default settingfor a new customer is typically 24 hours.

Feedback for a measurement period is stored in a database 3115,including the following information:

-   -   Required data:        -   Date and time of feedback        -   Subsystem related to the feedback:            -   Temperature            -   Light            -   Glare            -   Humidity            -   Noise        -   Feedback value (a value representing the feedback)        -   The control zone from which the feedback was taken        -   Associated subsystem settings at the time the feedback was            provided, such as:            -   Thermostat set-points and dead band            -   Lighting status:                -   On                -   Off                -   Percentage dimmed            -   Window shade position status            -   Humidifier/dehumidifier status            -   Ventilation fan status    -   Optional data:        -   Identity of the occupant providing the feedback        -   Sensor data for the area of feedback, if available, such as:            -   Temperature            -   Light level            -   Humidity level            -   Noise level

The user interface typically supports simultaneous feedback on multiplesubsystems. Each instance of feedback will create a separate record inthe database relating to the associated subsystem.

For the analysis phase, feedback is parsed for analysis according toassociated subsystems and control zones. Feedback for each subsystem isanalyzed independently of the feedback for other subsystems. Within eachsubsystem, feedback for each control zone is analyzed independently ofother control zones.

Feedback is pre-processed from individual occupants at step 3120. Thetreatment of multiple instances of feedback from individual occupants isdefined by the customer's policy settings 3160. Settings may becollective, applying to all occupants, or individual, applicable tospecific occupants. The purpose is to ensure that occupant feedback istreated “fairly”, as determined by the customer, and to eliminateintentional manipulation of the system.

Multiple instances of feedback from a single individual for a specificsubsystem and control zone during a single measurement period can behandled in several ways:

-   -   give each feedback instance the same weight as a single feedback        instance normally would have;    -   take the average of all instances of feedback and use this value        as a single feedback instance;    -   take the median value of all instances of feedback and use the        value of this as a single feedback instance; or    -   take the feedback value most frequently given during the        feedback period and use it as a single feedback instance.

It is recognized that the pre-processing of feedback may raise alerts3140 to the customer. For example:

-   -   If an occupant supplies inconsistent feedback, such as        registering both too cool and too warm during a measurement        period, this may raise an alert, and the customer may choose to        take action at step 3150, such as:        -   asking the occupant about the circumstances that gave rise            to the feedback; or        -   defining a policy for the specific occupant.

The feedback from specific occupants for specific subsystems and controlzones can be given different levels of weight as defined by customerpolicy. For example, the customer may decide that feedback fromresidents is given more weight than feedback from non-residents, or thatprofessors are accorded a higher weighting than students. Such weightingcan be included in the calculation of adjustment factors for a givensubsystem or control zone.

After the feedback from individual occupants has been processed, thenall feedback is analyzed statistically at the group level at step 3130for:

-   -   Distribution        -   Average        -   Median        -   Standard deviation        -   After elimination of a group of percentile outliers            (typically 90th percentile):            -   Average            -   Median            -   Standard deviation    -   Trends        -   Relative to sensor data        -   Relative to subsystem settings

The statistical analysis may also raise alerts 3140 to the customer thatindicate that facility systems are faulty or out of calibration, suchas:

-   -   Feedback about being too cold in spite of high thermostat        settings may indicate:        -   Open windows        -   Faulty thermostat calibration        -   Clogged filters    -   Feedback about being too noisy may indicate:        -   Faulty HVAC air handlers        -   Doors left open, which should be closed

Specific occupants consistently providing feedback that is divergentfrom the majority of occupants may indicate:

-   -   The occupant may need to be provided with things that improve        their comfort, such as:        -   Space heaters        -   Personal fans        -   Sweaters    -   The occupant may need to be relocated to spaces where the        settings would make them more comfortable, such as:        -   Less glare        -   Higher or lower temperatures        -   Less noise

The following feedback data received from a group of individuals is anillustrative example:

Comfort Value Count Extremely cold −4 1 Very cold −3 1 Cold −2 2 Cool −110 Comfortable 0 20 Warm 1 15 Hot 2 4 Very hot 3 1 Extremely hot 4 0In this example the average feedback value is 0.56 (“comfortable” with asmall “warm” bias), and the median feedback is “comfortable”.

If the 10% outliers are removed, the data becomes:

Comfort Value Count Extremely cold −4 0 Very cold −3 0 Cold −2 0 Cool −110 Comfortable 0 20 Warm 1 15 Hot 2 4 Very hot 3 0 Extremely hot 4 0Now the average feedback value is 1.44 (“warm”), and the median feedbackis “warm”.

With the outliers removed, there is a significant bias towards “warm” inthe feedback. Depending on the customer's policy settings, the season,the weather, or the influence of solar heating, etc., this might warrantdropping the thermostat's high set-point in summer, causing more energyconsumption for air conditioning, or dropping the thermostat lowset-point during the heating season, leading to a reduction in energyconsumption for heating.

In addition, occupant-level statistical analysis is also performed atstep 3130 for:

-   -   Distribution        -   Average        -   Median        -   Standard deviation        -   After elimination of specific percentile outliers (typically            ninetieth percentile)            -   Average            -   Median            -   Standard deviation    -   Trends        -   Relative to sensor data        -   Relative to subsystem settings

The following aggregate feedback received from an individual is anotherexample:

Comfort Value Count Extremely cold −4 1 Very cold −3 2 Cold −2 4 Cool −110 Comfortable 0 20 Warm 1 6 Hot 2 2 Very hot 3 1 Extremely hot 4 0

From the data, the average feedback from this individual Occupant is−1.66 (“cool”) and the median value is “comfortable”. If we again remove10% outliers, the average becomes −2 (“cold”) and the median remains“comfortable”. Depending on the customer's policy settings, an alert maybe issued that this occupant typically feels too cold.

For the adjustment phase 3170, the results of the statistical analysisfrom step 3130 and customer policy settings 3160 are fed to rules thatmanage the settings for the controls that adjust the subsystems andcontrol zones just analyzed. Examples of such rules are:

-   -   If more than a specified percentage of the processed feedback        reports the control zone as being uncomfortably hot, adjust the        thermostat set-points a predetermined number of degrees down.        -   Customer policy may limit this rule to specific levels of            occupancy. For example: Do not adjust set-points during            periods of no or low occupancy.    -   Adjust outside shades to block more direct sunlight if the        average processed feedback is uncomfortable glare.    -   Adjust outside shades to admit more direct sunlight if no        reported glare discomfort, and if daylight harvesting allows the        lowering of electric lighting levels.

Note that the adjustments typically will create an optimum balancebetween occupant comfort and energy consumption.

The system also includes a provision for policy override because someamount of discomfort may be desirable from a business perspective due tothe potential energy savings. Thus policy adjustment mechanisms areprovided to over-ride optimization to conform to such business policy.

An occupant feedback response 3190 is provided at all stages of feedbackprocessing. The types of response and when a response should be providedto the occupant who provides the feedback are driven by rules that takecustomer policy settings as input.

From the collection stage at step 3110, an immediate response isprovided to the occupant to show that each instance of feedback has beenreceived and will be processed. Responses may also include incentives orhistorical information, such as:

-   -   a rating of the occupant that indicates how often he/she        provides feedback;    -   adjustments that may have been made in response to previous        feedback from the occupant; and    -   rewards for particularly frequent or substantive participation.

From the analysis stage, all steps can result in responses to specificoccupants, to groups of occupants, or all occupants, depending onspecific conditions. As a result of pre-processing of feedback at step3120 from individual occupants, the occupants may be provided a feedbackresponse, such as:

-   -   reassuring occupants who have provided multiple instances of        feedback that their feedback will be processed, and to be        patient; and    -   informing occupants who appear to be attempting to manipulate        the system that there are other ways to address their        discomfort.        As a result of the group and occupant statistical analysis at        step 3130, a feedback response may be generated both to        individual occupants and to groups, such as:    -   The occupants may be provided feedback responses that indicate        group comfort levels combined with energy consumption data.    -   Individual occupants may be given feedback responses that they        are feeling discomfort when others are comfortable, suggesting        available remedial measures that the occupant may take        him/herself, or a response may be forwarded to a manager for        action.        -   Remedial measures that the occupant may be able to take            himself or herself:            -   Wearing warmer or cooler clothing.            -   Closing manual shades.        -   Potential management action:            -   Issuance of equipment that may make the occupant more                comfortable.            -   Relocating the occupant to a workspace that would be                more comfortable.

From the adjustments stage at step 3170, energy management settingadjustments can generate occupant feedback responses, such as informingall affected occupants of adjustments that have been made in response tooccupant feedback, with information about the impact of the adjustmenton comfort levels and energy consumption.

FIG. 18 is an exemplary user interface for feedback devices. As shown,the feedback interface 3500 is a window that includes a voting frame3510, a energy tracking frame 3520, and a results frame 3530. In thevoting frame, the user is shown a scale with the current temperature3512 and the user can vote on the perceived comfort level with thecurrent temperature using a slider 3514 and can add comments 3516. Byway of feedback, the user can also view results from others in the zoneor other locations, such as the temperature that others would like it tobe 3532 and the voting outcomes for today 3534. The user can also trackthe building's energy usage by a displayed temperature gauge 3522ranging from low to high. Additional encouragement to vote can beprovided by offering coupons or further applying gaming theory. Byproviding such feedback, it is hoped that employees will be willing tosacrifice some comfort for energy efficiency.

Returning to FIG. 1, each LEO 20-1, 20-2 and the central server 80include a respective rules engine 22-1, 22-2, 82 for processing data.While traditional programming could be used, the rules engines create aprogramming environment that is extremely close to a number ofreal-world situations. By using a rules engine, the programmer can focuson the business problem and not worry about traditional programmingconcepts such as program flow.

A rules engine, in accordance with particular embodiments of theinvention, operates on a set of rules, specified as “when <event> do<action>”. The rules engines detect the occurrence of events andautomatically execute the matching actions for rule-specified eventsthat have occurred. If an action creates the conditions specified by oneor more events, or possibly the same rule, they, in turn are executeduntil no more events are detected. In the terminology of rules engines,a rule is triggered when an event fires.

Ideally, the rules engine itself consumes few resources and leaves mostof the computer's resources to execution of the rule actions. Inpractice, however, rules engines often consume large amounts ofresources in the process of detecting events and triggering rules.

The most complex issues that contribute to rules engine overhead aredetection of events and chaining to rules, and state management.

For the detection of events and chaining to rules, the more general therules engine, and the more complex logic is allowed in the definition ofevents, the more difficult, and in turn, resource consuming does therules engine's logic for this process become. In the terminology ofartificial intelligence, a rules engine can be forward chaining, inwhich cases it detects an event then examines whether any rules existthat should be triggered by the event, or backward chaining, in whichcase the rules engine constantly watches the environment for conditionsthat satisfy the rule triggering logic.

Management of state by the rules engine is important and potentiallyvery complex. As a result, most rules engines are single-threaded—onlyone rule action can execute at a time. Multithreading can be desirableif some events take a long time to complete.

The order in which rule actions execute can also be important, if someevent triggers two rules, the final state can be different depending onthe order in which the rule actions execute. If the order is predictablethe rules engine is deterministic and if it is not, the rules engine isnon-deterministic.

An interesting case is the scenario where an event fires a rule, but forsome reason the conditions defining the event are not true at the timethe action executes. A real-world example is that a rule can specifythat a thermostat should be set at a comfortable level when an office isoccupied, and another rule states that different thermostat settingsshould be employed when the office is unoccupied. If the office becomesoccupied and triggers the first rule, but the event is not executeduntil the office becomes unoccupied, then the thermostat is adjustedunnecessarily. The second rule will fire when the office becomesunoccupied and if the rule actions execute in the order in which therules were fired, the thermostat will be set correctly after the secondrule performs its action.

The rules engines are frequently triggered by periodic events. As such,the system uses rules to maintain time data in a heartbeat table (notshown) and to process actions in response to changes in the time fields.

In accordance with a particular embodiment of the invention, a rulesengine addresses the issues described above by leveraging ACIDrelational database technology 24, 84 (FIG. 1) in the creation of rulesengines. Specifically:

-   -   Limiting the logic of the rule-triggering to “changes in the        data contained in one or more relational databases”, which        enables the rules to be very efficient in forward chaining by        employing database triggers to alert the rules engine when        rule-triggering modifications have been made.    -   Storing all of the state-critical data in one or more relational        databases and using the database engine to maintain consistent        state and ACID compliance.

In a particular embodiment of the invention, the ACID database isprovided by MySQL, version 5.2, paired with the InnoDB storage engine.The integration of ACID-compliant database technology has enabled anumber of other significant features and benefits. To maximize leverageof database technology and to make the rules engine as useful aspossible in a real-world application setting, the particular rulesengine has the following features:

-   -   1. Events are limited to changes in value to any of a number of        relational database columns. A single event can specify columns        in several tables and multiple columns in a single table.        Insertion of new rows and deletion of rows are considered        changes in value.    -   2. A rule event is tied to a triggering action happening to a        specific row in a table. If triggering events happen to multiple        rows in a table, they generate separate calls to the rule        action. The rule action knows the specific table, row and column        that triggered it.    -   3. Rule actions must assume that the state of the system may        have changed between the event and the time the action is        performed, including changes to database columns that trigger        the event.    -   4. If multiple event-triggering columns for the same rule are        changed simultaneously they will cause multiple executions of        the rule event. One for each column that had its value changed.    -   5. All actions are transactional and ACID:        -   Rule actions are Atomic, meaning that they either complete,            or all changes to the database are rolled back if the            actions fail, for any reason.        -   The data in the database is Consistent, meaning that all            actions see a consistent state.        -   All actions are Isolated, meaning that if an action modifies            database data used by some other action, the second action            will be suspended until the first action completed.        -   All actions are Durable, meaning that changes to the            database performed by an action are guaranteed to survive            any failure.    -   6. Rule triggering and rule action execution is asynchronous:        -   Rule trigger detection and rule action execution run            independently of one another, the former feeding a queue and            the latter consuming it.        -   Events are not triggered by a rule until it completes and            commits.    -   7. All rules have an assigned priority:        -   If single-threaded rule execution is chosen, rule action            execution order is strictly by increasing priority and            increasing triggering timestamp.        -   If multi-thread rule execution is chosen, each thread            chooses rules to execute in the order of increasing priority            and increasing triggering timestamp, but since a thread can            be limited to a range of priorities and the nature of            multi-threading, overall rule action execution is not            guaranteed to be in increasing priority and increasing            triggering timestamp order.

The particular rules engine applies the capabilities of modernACID-compliant relational databases to the domain of rules engines in aunique and innovative manner to implement a rules engine with a numberof unique and desirable features:

-   -   1. Triggering a rule in response to changes to specific columns        in any row of specific tables.    -   2. Scaling of rules to work efficiently on massive amounts of        data by allowing one rule to operate on all rows of database        tables containing potentially massive amounts of data. In        effect, the rules engine will scale as efficiently as the        database engine it leverages.    -   3. Multiple instances of the same rule, triggered by different        rows or columns, can execute in parallel.    -   4. Multi-threaded triggering and execution of rules.    -   5. Asynchronous triggering and execution of rules.    -   6. Rule triggers and rule actions triggered can be guaranteed        against loss by any failure short of a catastrophic event.    -   7. ACID compliance:        -   a. Atomicity of rule execution;        -   b. Consistency of overall system state;        -   c. Isolation of one executing rule from other executing            rules; and        -   d. Durability of rule execution.    -   8. Failing rules are retained and can be restarted after the        cause of the failure has been corrected.    -   9. The balance of throughput and responsiveness of rules can be        managed by assigning priorities and having multiple execution        threads assigned to subsets of priorities.

FIG. 19 is a block diagram of a rule definition in accordance withparticular embodiments of the invention. As shown, a rule 4000 isdefined by specifying three items:

-   -   1. the event definition 4010, which is the data that will        trigger the rule;    -   2. the action 4020 the rule should perform when triggered; and    -   3. the priority of the rule 4030.

Triggering data is data that, if changed by database inserts, deletes orupdates, will trigger rules. The definition includes a list of table andcolumn pairs. The list of tables can include multiple tables 4081, 4082,. . . , 4089 and multiple columns 4081-A, 4081-B, 4082-C, . . . , 4089-Dwith no restriction other than all the tables must be under the controlof a single transaction manager. Pointers 4015 are used to access thetable columns.

The action to be performed when triggered is machine-executable codethat must be run after the rule is triggered.

Rules are created by adding entries to a rule definition table thatcontains the identity of the rule, the trigger definition, the actioncode and the rule priority. Depending on the implementation, any or allof these fields can be pointers to data external to the database orcontained in data or code external to the database.

FIG. 20 is a flowchart of a particular rules engine in accordance withparticular embodiments of the invention. The rules engine 4100 isresponsive to database modifications. As shown, a process P runningoutside the scope of the rules engine 4100 makes a change to data in theACID database 4080. At step 4110, the database engine triggers an eventfor a table specified in the rule events 4010 (FIG. 19) and an entry isplaced in an event queue 4120. At step 4130, the event queue entries aretranslated into rule execution queue entries and placed in a ruleexecution queue 4140.

The entries on the rule execution queue 4140 are processed by processes4020-1, 4020-2, . . . , 4020-R executing the specified rule action 4020(FIG. 19). As shown, the processes can run in parallel. The power of therules engine can be appreciated by the fact that the rule actions canresult in modification to the database, which can also trigger furtherrules.

FIG. 21 is a flowchart of rule triggering logic of FIG. 20. Ruletriggering 4110 is performed by database triggers attached to the tablesthat are defined in rule trigger definitions. The database triggers areexecuted on insert, delete and updates to the tables 1081 by any processP. At step 4112, the triggers examine the before and after contents ofall columns named in trigger definitions. If there is no change, then noaction is taken at step 4114. But for each column in which the data haschanged, the trigger will add an entry at step 4116 to an event queuetable 4120, which includes the table name, the column name, the actionthat caused the change (insert, delete or update), and the primary keyvalues of the database row containing the change.

One advantage of using database triggers is that the process making thechange to the data is unaware of the triggering, and that the triggerwill capture any modification to the data, no matter how it is made.Finally, the triggering code is run in the context of the transaction ofthe modifying query and follows the ACID compliant rules. Specifically,if the modifying code fails and the transaction is rolled back, theentry into the event queue will also be rolled back and removed.

FIG. 22 is a flowchart for translation of event queue entries into ruleexecution queue entries from FIG. 20. The event queue table data 4120 isconsumed by a process at step 4131 that reads entries from the queue4120 and compares the contents of the entry with the event definitionsof all rules 4010. At step 4132, for each rule for which the eventdefinition includes the table and column in the queue entry the processperforms the following:

-   -   At step 4133, a rule execution queue entry is created that        includes a rule identifier, the table name, the column name, the        primary key values, and the action from the event queue entry.    -   At step 4134, the process examines the contents of a rule        execution queue table. A row in the rule execution queue table        includes the identity of a rule, the name of the triggering        table, the name of the triggering column, the primary key values        of the row that triggered the rule, the action that caused the        trigger (insert, delete, or update), the state of the entry, the        priority of the rule, and the date and time the row was placed        in the queue.    -   At step 4135, if no entry was found in the rule execution queue        that matches the rule identifier, the table name, the column        name, the primary key values, and the action from the event        queue entry, a new rule execution queue entry is added at step        4136 that includes the identity of the rule, the data from the        event queue table, the rule priority and current date and time.    -   If an entry was found at step 4135, then processing continues to        step 4137 where the entry's state is examined and depending on        its value, one of the following actions is taken:        -   If the state is waiting to be run no action is taken.        -   If the state is failed, no action is taken.        -   If the state is running, the state is modified to running            and waiting to be re-queued.        -   If the state is running and waiting to be re-queued no            action is taken.

At step 4138, if there are more rules that match the event queue entry,then processing returns to step 4133 to process the next rule. Uponcompletion of these actions the entry in the event queue table isdeleted at step 4138 and processing returns to step 4131 to process thenext event queue entry. Each event queue entry is handled in atransaction, ensuring that it either completes, and is deleted, orrolled back, and stays in the queue.

FIG. 23 is a flowchart of rule execution logic of FIG. 20. As notedabove, execution of rules 4020 can be done in parallel by multipleprocesses, and can be distributed where execution processes run onmultiple servers. Each rule execution process works from the ruleexecution queue 4140 (FIG. 20) by the rule execution process continuallyexecuting the following logic:

-   -   Depending on how it is set up, a rule execution process can be        configured for a subset of possible priorities. In a single        transaction, the highest priority, oldest (defined by the        submission date and time) rule execution queue entry that        matches the priority configuration of the process, and has a        state of waiting to be run is selected at step 4021. At step        4022, its state is changed to running, and the transaction is        committed. The code of the rule is then called at step 4023,        passing the data from the queue entry as parameters.    -   If the code returns without failure at step 4024, the queue        entry is retrieved again (it may have been modified in the        meantime), and its state is examined and the following actions        taken based on the state:        -   If the state is running at step 4026, the queue entry is            removed at step 4027.        -   If the state is running and waiting to be re-queued at step            2046, the state is modified to waiting to run at step 4028.    -   If the rule code returns a failure at step 4024, the current        transaction is committed, a new transaction is started and the        queue entry state is modified to failed at step 4029.    -   The current transaction is then committed to the database.

In addition to the above, database event triggers can be automaticallycreated. By examining the totality of rules the aggregate set ofrule-triggering table/column pairs can be ascertained. By maintaining astrict naming convention for the rules engine-generated databasetriggers the rules engine can automate the management of them. When arule is created, deleted or modified, the rules engine will generate thesource code for the required database triggers. If the database engineprovides a facility for examining the source of installed triggers, theengine can compare those required with those installed and delete thoseno longer required, create new ones required and modify those where thegenerated source is different from the installed.

Furthermore, rules in a running rules engine can be updated with nodisruption by updating the system as follows:

-   -   Stop processing of the event queue.    -   Wait until the rule execution queue contains no entries for        rules that will be deleted or modified.    -   Update the database triggers to conform with the new        configuration.    -   Update the rule definition table.    -   Resume processing of the event queue.

Performance of the rules engine can be increased by caching read-onlydata. In particular, when there is a high probability that the same datawill be executed multiple times in a single process, the performance ofthe second and subsequent executions can be increased by passing eachinstance of the rule a pointer to an in-memory data structure that willbe passed to all instances running in that process. The first instancemay determine that the data structure does not contain the read-onlydata and read it from the database or some other data source. Subsequentinstances may examine the data structure and determine that it containsthe read-only data and use the in-memory contents.

The same data structure can be used for instance-to-instancecommunication within a single process that does not need to be managedtransactionally.

Finally, a failed rule instance (where the rule execution queue state isfailed) can be restarted by changing the state to waiting to be runafter the condition causing the failure has been corrected. The failurecorrection can include updating the rule logic as described above.

It may be desirable to run the failed rule without changing its initialstate for diagnostic purposes, or to validate that the error-causingcondition has been corrected. This can be done by running a process(possibly under debugger control) that selects the failed rule from therule execution queue, but otherwise follows the same logic as described.

If a rule action performs aggregate functions, such as operating acrossmultiple rows, it can be undesirable to have rule instances for eachmodified row. For example, if a rule calculates the sum of the values ofa column across an entire table, the rules engine can place multipleinstances of the rule in the rule execution queue, all waiting to beexecuted. When the first instance executes, the sum will be calculated,and subsequent instances will calculate the same sum and, in effect, dono useful work.

To eliminate that wasted resource use, the particular rules engineallows the rule so specify a piece of code to be executed as the eventqueue entry is translated to a rule execution queue entry. This code isgranted modification access to the rule execution queue entry before thequeue is scanned for the same entry. By modifying the entry it canmanipulate which existing queue entries it will match. For example, inthe previous example, if the field containing the primary key values ismodified to a constant value, triggering from different rows will createthe same rule execution queue entry and only one instance will exist inthe queue at any time.

FIG. 24 is a flowchart of a process for translation of event queueentries into rule execution queue entries from FIG. 22 to include queueentry modification. As shown, the modified translation process 4130′includes the same steps as the translation process 4130 of FIG. 22except that after step 4133, a call is made at step 4133′ tomodification code for the rule. In that case, the process continues tostep 4134 by using the returned queue entry.

FIG. 25 is a block diagram of rule definition components of FIG. 19modified to support execution queue entry modification of FIG. 24. Themodified rule 4000′ includes the event definitions 4010, actions 4020,and priority 4030 components of FIG. 19. As shown, the modified rule4000′ includes execution queue modification logic 4040′.

The ability to manipulate the rule execution queue entry is extremelypowerful and useful in a number of other instances.

Finally, the ability to schedule rule actions other than through thepreviously described database triggers extends the scope of eventsbeyond the modification of database table values. In effect, it allowsany piece of software, including rule actions, to raise events andtrigger rule execution.

The particular rules engine provides three mechanisms toprogrammatically trigger rules:

-   -   1. An Application Programming Interface (API) call that adds an        event queue entry.    -   2. An API call to the event queue to rule execution queue logic        with arguments matching the contents of an event queue entry.    -   3. An API call to the rule execution queue insertion logic with        arguments matching the contents of a rule execution queue entry.

These API entries provide a completely generalized interface for codethat programmatically raise events and schedule rule execution.

It is anticipated that the described technologies can be applied toareas beyond facilities management and energy conservation, and thatthose of ordinary skill in the art will recognize many otherapplication. Some other applications include, but are not limited to:

-   -   Market predictions (stock markets are only one market; we could        just as easily predict retail, commodities, political forecasts,        etc.)    -   Energy rate “surfing” that allows the customer to direct energy        consumption based on predicted energy-pricing market behaviors.    -   Energy grid management    -   Retail spot-advertising (to appear on screens in shopping malls        when we predict >X numbers of people of Y demographic will be in        Z area. The demographic data can be obtained by:        -   Discern the data based on circumstances, such as a movie            getting out, time of day, calendar, activities at nearby            demographic-specific stores, etc., which form patterns over            time.        -   Determine the data by associative behavior, such as the            reaction to specific adverts in the past or present.        -   The people provide the data by registering (social awards,            gaming theory, and other incentives)        -   The people provide the data by logging in through Google or            Facebook.        -   The people provide the data by reacting to the advert, such            as by:            -   Logging in to a web site or camera-shooting the                geo-location code in the advert for a coupon.            -   Shooting the ad as a coupon and walking into a store                looking for a discount, where their demographic is                recorded for later correlation.        -   Pattern recognition cameras (often used in security            systems).        -   Spotters observe the demographics and record for            correlation.    -   Medium or long-range budget forecasting for anything related to        human patterns or space planning, such as energy budgets,        technology budgets, etc.    -   Any prediction of a macro environment from a micro environment.

Those of ordinary skill in the art should recognize that methodsinvolved in the automated facilities management system may be embodiedin a computer program product that includes a computer-usable medium.For example, such a computer-usable medium can include a readable memorydevice, such as a solid state memory device, a hard drive device, aCD-ROM, a DVD-ROM, or a computer diskette, having computer-readableprogram code segments stored thereon. The computer-useable medium canalso include a communications or transmission medium, such as a bus or acommunications link, whether optical, wired, or wireless, having programcode segments carried thereon as digital or analog data signals.

While this invention has been particularly shown and described withreferences to particular embodiments, it will be understood by thoseskilled in the art that various changes in form and details may be madeto the embodiments without departing from the scope of the inventionencompassed by the appended claims.

1. A system for automatically managing a facility, comprising: aplurality of sensor devices providing sensed data; a plurality ofcontrol devices for actuating facility devices; a data store having aplurality of patterns related to the sensor devices; a processor coupledto the data store, the sensor devices, and the control devices, theprocessor being responsive to the sensed data over time from the sensordevices to: store the sensed data over time in the data store; calculatethe best match pattern from sensed data over time and the plurality ofpatterns; predict future sensed data from the best match pattern; andsignal a control device based on the predicted future sensed data. 2.The system of claim 1, wherein the sensor devices are occupancy sensors.3. The system of claim 1 further comprising a building management systemdisposed between the processor and the control devices.
 4. The system ofclaim 1, wherein the data store includes a relational database.
 5. Thesystem of claim 4, wherein the relational database is ACID compliant. 6.The system of claim 1, wherein the patterns include expected sensor datafor an interval of time.
 7. The system of claim 6, wherein the intervalof time is divided into equal length time slices.
 8. The system of claim1, wherein the processor includes a rules engine.
 9. A method forautomatically managing a facility, comprising: receiving sensed datafrom a plurality of sensor devices providing sensed data; providing aplurality of control devices for actuating facility devices; storing aplurality of patterns related to the sensor devices in a data store;coupling a processor coupled to the data store, the sensor devices, andthe control devices, the processor being responsive to the sensed dataover time from the sensor devices to: store the sensed data over time inthe data store; calculate the best match pattern from sensed data overtime and the plurality of patterns; predict future sensed data from thebest match pattern; and signal a control device based on the predictedfuture sensed data.
 10. An article of manufacture, comprising: amachine-readable medium; a set of program code segments embodied on themachine-readable medium, the program code segments including machineinstructions for a method for automatically managing a facility, themethod comprising: receiving sensed data from a plurality of sensordevices providing sensed data; providing a plurality of control devicesfor actuating facility devices; storing a plurality of patterns relatedto the sensor devices in a data store; coupling a processor coupled tothe data store, the sensor devices, and the control devices, theprocessor being responsive to the sensed data over time from the sensordevices to: store the sensed data over time in the data store; calculatethe best match pattern from sensed data over time and the plurality ofpatterns; predict future sensed data from the best match pattern; andsignal a control device based on the predicted future sensed data.